Technical Q&A

DV36 - MemAllocatePhysicallyContiguous (23-August-1999)

Q: My driver needs to allocate physically contiguous memory. I'm calling MemAllocatePhysicallyContiguous but it returns nil, even though the system has plenty of free memory. What can I do?

A: MemAllocatePhysicallyContiguous uses a very naive algorithm to find physically contiguous memory. The gist of the algorithm is shown below.

on MemAllocatePhysicallyContiguous size
    result = NewPtrSys(size)
    if result != nil then
        if LockMemoryContiguous(result, size) != noErr then
            previousResult = result;
            result = NewPtrSys(size)
            if result != nil then
                if LockMemoryContiguous(result, size) != noErr then
                    DisposePtr(result)
                    result = nil;
                end-if
            end-if
            DisposePtr(previousResult)
        end-if
    end-if
    return result
end MemAllocatePhysicallyContiguous

Note:
The above pseudo-code is a rough description of the MemAllocatePhysicallyContiguous algorithm. The actual code is more complex, partly because the buffer returned by MemAllocatePhysicallyContiguous is always page-aligned.


This algorithm is not particularly smart about finding physically contiguous memory. Specifically, the algorithm only makes two attempts to find a physically contiguous block. If both attempts fail, MemAllocatePhysicallyContiguous gives up and returns an error. There may be plenty of memory, there may even be plenty of physically contiguous memory, but MemAllocatePhysicallyContiguous won't find it.

There are a number factors that determine whether the LockMemoryContiguous call used by MemAllocatePhysicallyContiguous succeeds.

  • Before VM loads, the relationship between logical and physical addresses is relatively simple. Typically there is a direct map between logical and physical addresses. However, this is not always true.
    • ROM-in-RAM computers have a number of discontinuities in the logical-to-physical mapping because of the way the system transitions from Open Firmware to Mac OS, and how the system loads the Mac OS ROM file into memory. For more background on this issue, see DTS Q&A DV 33 PrepareMemoryForIO in the NewWorld.
    • These discontinuities are not a new thing. Historically, computers such as the Mac IIci used the Memory Management Unit to “stitch” together banks of RAM that are discontiguous in the physical address space.

    Your driver may encounter these discontinuities at boot time, depending on the hardware platform, the RAM configuration, the time your driver loads, and the amount of memory consumed by other drivers that loaded before you.

  • After VM loads, the relationship between logical and physical addresses quickly becomes scrambled.
  • The ROM contains a primitive version of LockMemoryContiguous that simply checks whether the memory is physically contiguous and returns cannotMakeContiguousErr if it isn't. If you try to get physically contiguous memory before VM loads (or at any time on a system with VM disabled), you will use this version of LockMemoryContiguous.
  • The Virtual Memory Manager re-implements LockMemoryContiguous with a somewhat smarter algorithm. If VM is enabled and you try to get physically contiguous memory after VM loads, this new algorithm will work harder to find a physically contiguous range of memory. However, a request for a large block of physically contiguous memory is still likely to fail.

In summary, the ability of the system to provide physically contiguous memory is extremely limited, and extremely sensitive to environmental factors.

That’s the bad news. The good news is that you can do things to work around this limitation:

  • Smaller Memory Allocations—The smaller the memory allocation, the greater chance that it will be physically contiguous. [In the limiting case, it is always possible to allocate one page of physically contiguous memory.] Allocating one huge physically contiguous block is the worst case scenario. You may be able to restructure your driver to use a number of smaller blocks.
  • Early Memory Allocation—The earlier you load, the more likely that you can allocate physically contiguous memory. Some drivers defer memory allocation until they are opened, and then fail to get physically contiguous memory at that time. To prevent this, you can allocate your memory early in the startup process by marking your driver with the kDriverIsLoadedUponDiscovery flag. You can then use the pre-allocated memory when your driver is opened.
  • Deferred Memory Allocation—When you can't allocate memory at startup time, you can try again later, either when your driver is opened, or when it is tickled by some other service that loads later in the startup process. This deferred allocation may succeed because of VM’s improved LockMemoryContiguous algorithm.
  • Scatter/Gather—Most DMA hardware supports a scatter/gather mechanism. [Scatter/gather hardware is a requirement on OS’s which provide no way to allocate physically contiguous memory.] Many developers are reticent to enable scatter/gather because it is less efficient (it typically consumes PCI bus cycles fetching the descriptors) and harder to program. However, scatter/gather is the ultimate solution to MemAllocatePhysicallyContiguous returning nil.

You will get best results by using a combination of these techniques. If your card gains significant performance benefits from using physically contiguous memory, you should try to allocate that memory using the techniques described above. If all your attempts to allocate physically contiguous memory fail, you should ultimately be prepared to enable the scatter/gather mode on your hardware.

-- Quinn "The Eskimo!"
Worldwide Developer Technical Support

Technical Q&As | Contents
Previous Question | Next Question

To contact us, please use the Contact Us page.